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Description 

[0001] The present invention pertains to user-charac- 
terizing network protocol headers, such as so-called In- 
ternet "cookies," which are used by Internet content pro- 
viders for various reasons, but in particular for providing 
information about a user to a website operated by the 
Internet content provider. More particularly, the present 
invention pertains to a system for managing such pro- 
tocol headers, enabling a user to interpret and, prefer- 
ably, adjust the content of the protocol headers. 
[0002] An Internet cookie is a protocol header consist- 
ing of a string of characters (cookie content) that is in- 
serted by a web server, operated by an Internet Content 
Provider (ICP), into the random access memory (RAM) 
on a user's computer (client) while the user is operating 
a browser (application program) to access web pages 
on the Internet, typically through an Internet Service 
Provider (ISP) using the World Wide Web (type of net- 
work operating system). An ICP may also be an ISP, as 
in the case of, for example, American On Line. 
[0003] A web server may "set" a cookie at various 
points during a user's access of the web server. The 
string of characters or content comprising a cookie 
specifies a domain, path, lifetime and value of a variable. 
The variable may be, for example, the number of times 
the user has visited the web server or particular web 
pages provided by the web server, and the domain and 
path indicate a website (a group of similar web pages 
operated by a single entity). If the lifetime of the cookie 
is greater than the time the user spends at the website, 
then the cookie may be saved in a cookie file (file of 
cookies) for future reference by either the user, the web 
server setting the cookie or other web servers. 
[0004] Cookies are set for many different reasons, in- 
cluding enabling a web server or an ICP to customize 
the information it provides to a user, to facilitate on-line 
sales or services (e.g., implementing a so-called "shop- 
ping basket"), for tracking web pages the user has vis- 
ited, or for providing the web server or (CP's website 
with some demographic information (presumably only 
geographical information or at what time a user tends to 
visit the ICT's website). 

[0005] The idea behind the use of protocol headers 
such as cookies is to enable a web server or ICP to gath- 
er information about a user. By setting one or more long- 
lived cookies in a users cookie file, the next time the user 
accesses the website, the ICP can know certain infor- 
mation about the user that will, in theory, facilitate the 
user's productive use of the information accessible at 
the ICP's website. This works because when an ISP di- 
rects a user to a website, the browser on the user's com- 
puter examines its cookie file for cookies that have been 
set by the website and provides those cookies to the 
website byway of introducing itself (representing the us- 
er) to the website. The website may then, or sometime 
later, set new cookies on the user's computer, or alter 
the value of cookies previously set there. 



[0006] Cookies are also used to securely store per- 
sonal data a user has shared with a website. As men- 
tioned above, cookies set by an ICP in the RAM of a 
user's computer end up stored in a file on the user's hard 
5 drive if the lifetime of cookie is longer than the time the 
user spends at the ICP's website. All such cookies are 
stored in a single file on the user's hard drive (a file usu- 
ally called "cookies.txt"). 

[0007] More browsers today, including Netscape and 
10 Microsoft Internet Explorer, can be configured to display 
to a user a warning that a cookie is about to be set, and 
to give the user the option of blocking the cookie. The 
user is often even able to view the content of the cook- 
ies. However, the user often has no knowledge of the 
15 meaning of the content of the cookie nor the intended 
use for the cookie contents by the ICP. in some cases, 
when a user blocks an ICP from setting a cookie, the 
ICP's website refuses to allow access to the website by 
the user. Since there are many innocuous and quite use- 
20 ful reasons for a website to set a cookie, it is probably 
not, as a general rule, in the user's best interest to simply 
block all cookies. 

[0008] In addition to configurable software for disa- 
bling a website from setting a cookie in the first place, 

25 the prior art includes a number of applications intended 
to assist a user in removing the file of long-lived cookies 
(the cookie file). Both the cookie-blocking browsers and 
cookie file managers indicate to a user the identity of the 
website responsible for each cookie intended to be set 

30 or stored in the cookie file. Identifying the website that 
set a cookie is easy because, as indicated above, each 
cookie includes, as text, the path and domain for the 
website that set the cookie. The prior art also includes 
software that will enable a user to remove sensitive in- 

35 formation from the user's browser cache and cookie 
files. 

[0009] US 5467472 relates to generating and main- 
taining property sets is provided. In a preferred embod- 
iment, a property set stream is generated. The stream 

40 comprises three parts: a header, a section locator array, 
and one or more sections. The header contains infor- 
mation for uniquely identifying the property set and for 
identifying the number of sections within the property 
set. The section locator array contains a unique identi- 

45 fier for each section and an offset indicating where the 
section resides within the stream. The third part, the sec- 
tion definitions, contains the information necessary to 
maintain groups of properties for each section. Each 
section contains a section header, a property locator ar- 

50 ray, and an array of property type- value pairs. The sec- 
tion header indicates both the size of the section and 
the number of properties defined within the section. The 
property locator array contains unique property identifi- 
ers for each property defined in the section and a relative 

55 offset, from the beginning of the section, to the property 
definition. Each property definition appears as a type/ 
value pair, the type indicator indicating the data format 
for the property and the value field containing or refer- 
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encing the data. In a preferred embodiment, a property 
set is generated by allocating appropriate storage and 
by storing values in the standard structure for a property 
set. 

[001 0] US 5754872 discloses how in a character rec- 
ognizing system having a plurality of terminals intercon- 
nected by a network, a dictionary for recognizing a char- 
acter pattern inputted in an image form maybe distrib- 
uted to each terminal. When a dictionary necessary for 
recognizing a character pattern inputted from one ter- 
minal is not provided in that terminal, the character pat- 
tern is transferred through the network to another termi- 
nal in which the necessary dictionary is provided, and is 
recognized by the other terminal. Each terminal is pro- 
vided with a function of specifying a terminal having a 
dictionary necessary for recognizing the inputted char- 
acter pattern. For example, characters offering keys are 
defined beforehand and each terminal is provided with 
a dictionary capable of recognizing the key characters 
and a table indicative of a relationship between the key 
characters and terminals corresponding to the key char- 
acters, whereby one terminal is specified in accordance 
with a key character. 

[0011] The document XP 002188264 "Utility Guide 
98, Cookie Managers* published in PC Magazine Online 
on March 24, 1998 describes a number of cookie man- 
ager utilities, some of which only block cookies but oth- 
ers of which will delete cookie files that already reside 
on a user's system. Some utilities allow a user to exam- 
ine cookie files and select which ones to keep in order 
to afford the user greater control. Some utilities include 
privacy features that clean browser caches and history 
files. 

[0012] Accordingly, the present invention has an ob- 
ject of interpreting for a computer user the content of a 
user-characterizing protocol header, such as an Internet 
cookie, and, optionally, adjusting its content. 
[0013] It is another object of the present invention to 
enable such a user to fabricate a user-characterizing 
protocol header having content of the user's own crea- 
tion, and thereby convey to a website information the 
user wants to convey. 

[001 4] Correspondingly, it is a still further, optional ob- 
ject of the present invention to provide a means by which 
a website receiving from a user a protocol header fab- 
ricated by the user can interpret the protocol header if 
its interpretation is not apparent from inspection. 
[001 5] According to the present invention there is pro- 
vided a system for interfacing with a string of characters 
defining a protocol header in accordance with the ap- 
pended claim 1 ; preferred embodiments of the invention 
are defined in the dependent claims. 
[0016] The invention itself, as well as other features 
and advantages thereof, will be best understood by ref- 
erence to the detailed description when read in conjunc- 
tion with the accompanying drawings, of which: 

Fig. 1 is a block diagram of a system for managing 



an Internet cookie according to the present inven- 
tion; 

Fig. 2 is a block diagram of a system for managing 
a user-characterizing protocol header according to 
5 the present invention; and 

Fig. 3 and Fig. 4 in combination are a flow chart for 
managing a user-characterizing protocol header 
according to the present invention. 

10 [001 7] What the prior art does not provide is a means 
by which a user can, using the same mechanism for ex- 
changing information about who the user is, convey to 
a website preferences the user may wish to convey, in- 
stead of only preferences the website has deemed use- 
's ful to know. For example, a user may wish to communi- 
cate to a website that the user would prefer to receive 
any advertising, demonstration material or other kinds 
of literature as postal mail or through a courier service. 
[001 8] What stands in the way of communicating such 
20 preferences is that the ICP website that sets a cookie 
sometimes does not have variables (types of cookie) 
that are appropriate for what the user wants to express. 
What is needed is a means by which a user can not only 
identify and delete a cookie file or delete particular cook- 
25 jes within a cookie file or still in RAM, only guessing what 
the cookies content conveys, but a means of actually 
interpreting the content of the cookies within a cookie 
file or still in RAM, and also a means by which a user 
can create new types of cookies (cookies with new var- 
30 iables) that may be offered to a website of an ICP. 
[001 9] To achieve these objects, the present invention 
interfaces with a string of characters defining a protocol 
header on a user's computer to provide a user with an 
interpretation of at least a portion of the string of char- 
ts acters, the invention comprising: a dictionary containing 
at least one entry, the entry comprising a first string of 
characters representing at least a portion of the protocol 
header and a second string of characters representing 
a meaning associated with the first string of characters; 
40 an interpreter for retrieving the second string of charac- 
ters based upon the first string of characters; and an 
editor, for displaying the second string of characters re- 
trieved by the interpreter. 

[0020] The present invention is hereinafter described 
45 jn a particular context of the Internet, namely where a 
user operates a computer attached to the Internet, and 
accesses websites of Internet content providers through 
the World Wide Web, using a browser, which, as part of 
the World Wide Web protocol, allows websites to set on 
50 the user's computer so-called Internet cookies, which 
are a kind of user-characterizing protocol header. The 
present invention, however, need not find application 
only on the Internet, or only in the World Wide Web en- 
vironment of the Internet. Instead of the Internet, the 
55 present invention can be used on any network in which 
there is, as a protocol between sites of the network, the 
setting of user-characterizing protocol headers by a 
computer at one site onto the computer at another site. 
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Thus, the network can be different than the Internet, the 
network operating system can be different than the 
World Wide Web, the site interfacing software for inter- 
facing with a server at a site of the network can be dif- 
ferent than the browsers of the World Wide Web, and 
the protocol headers exchanged between sites can be 
different than cookies, but are still a user-characterizing 
protocol header in the sense that an Internet cookie 
characterizes a user for a website. 
[0021] The cookies that are managed by the present 
invention can be on the user's computer; they may re- 
side in random access memory (RAM), or in non-volatile 
storage, such as the user's hard drive. 
[0022] The preferred embodiment of the present in- 
vention includes a data dictionary, on the user's compu- 
ter, that serves as a basis by which the present invention 
interprets cookies on the user's computer. This data dic- 
tionary is here called a local cookie dictionary, and its 
entries are types of cookies, or, equivalently, cookie var- 
iable types. The local cookie dictionary is the dictionary 
routinely used, in the preferred embodiment, to interpret 
cookies. It is the data dictionary first referred to. Any da- 
ta dictionary used as such a principal reference, is here 
called a principal dictionary. Such a data dictionary need 
not be on the user's computer. Instead, it may be re- 
mote. 

[0023] For each entry in the local cookie dictionary, L 
e., for each type of cookie, the local cookie dictionary 
provides content data indicating an interpretation of any 
particular cookie of that type, including an explanation 
of the cookie type, i.e., the cookie variable, and informa- 
tion about the possible values that can be assigned to 
the cookie. The interpretation for each entry is sufficient 
for building a template out of which a cookie can be fab- 
ricated; to enable building such a template, content data 
for an entry includes an indication of how to parse any 
associated cookie. For some Internet cookies, those 
that rely on a tab to delimit the fields of a cookie, the 
parsing information simply indicates the use of tab-de- 
limited fields. 

[0024] The invention further provides a cookie editor 
that enables the user to manage the cookies on the us- 
er's computer. The cookie editor does not, however, ac- 
cess the cookies directly; instead the editor interfaces 
with a cookie interpreter that interprets each cookie, 
based on the local cookie dictionary. The interpreter not 
only provides an interpretation of cookies, but also pro- 
vides information, as part of the interpretation, of the 
possible values of the cookie. In the basic invention, the 
cookie interpreter merely provides to the cookie editor 
an interpretation of a cookie, which the editor then dis- 
plays. For example, the editor displays a cookie in a way 
that explains each textual character or logically related 
set of textual characters making up the cookie. In the 
preferred embodiment, the user never even views a 
cookie in its native format, i.e., in the format in which it 
would appear if it were accessed using a generic text 
editor. 



[0025] In optional enhancements of the basic inven- 
tion, the cookie editor enables the user to alter the val- 
ues of cookies. 

[0026] In a further optional enhancement, the inter- 
5 prefer lets the user, through commands to the editor, 
scroll through the local cookie dictionary and view cook- 
ie types the user might want to use to express to a web- 
site preferences the user might have, such as prefer- 
ences the user might have related to how the website 
10 sends the user advertising. For example, the user might 
want to express to a website that the user would prefer 
that any advertising the website owner might send to the 
user be sent by postal mail. In that case, the user would 
select from the local cookie dictionary a cookie for ex- 
's pressing how the user would like to receive advertising, 
and would indicate, as a value for this cookie, postal 
mail. The user would also indicate to the editor the web- 
site that is to receive the cookie so that the editor can 
make the cookie into one for that website. How the web- 
site would interpret the cookie is addressed in further 
refinements of the basic invention, but if the cookie is 
intentionally made to be clear in what it is communicat- 
ing, the cookie could be interpreted by the recipient with- 
out any sort of dictionary. 

[0027] As explained above, the interpreter stands be- 
tween the user, acting through the editor, and the cookie. 
The interpreter ensures the integrity of the cookie by 
preventing the user from fabricating a cookie or altering 
a cookie so as to produce a cookie not according to 
proper format. 

[0028] As an optional enhancement, to provide for 
sharing of information about the types of cookies set by 
different websites, and also the types of cookies the user 
might want to fabricate, the invention makes accessible 
over the Internet both a site-specific cookie dictionary 
providing an interpretation of the different variables 
used by different websites and identifying which web- 
sites uses which variables, and also a universal cookie 
dictionary providing an interpretation of cookie types for 
expressing a preference to a website. 
[0029] Referring now to Fig. 1 , a system for managing 
Internet cookies, either in a cookie file 10 or RAM (not 
shown), is shown, in the preferred embodiment, to in- 
clude a cookie interpreter 1 5, which uses entries (cookie 
types) and corresponding cookie interpretations in a lo- 
cal cookie dictionary 17, managed by a local cookie dic- 
tionary manager 16, to provide to a user, through a cook- 
ie editor 13, interpretations of cookies. The cookie file 
10 is read from and written to, from time to time, by a 
browser 11 operated by the user. With the browser, the 
user accesses, through an Internet service provider 
(ISP) 12, different cookie-setting websites of different In- 
ternet content provider 23 (ICPs). In the preferred em- 
bodiment, the invention also includes a site-specific 
cookie dictionary 21 located at a website accessible 
over the Internet, as well as a universal cookie dictionary 
22, located at a website accessible via the Internet. 
[0030] The first time this invention is used, it provides 
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the user with typical personal information and cookie 
content on which the user might want to base genera! 
preferences for information that might be conveyed by 
a cookie. The user may set these general preferences 
to allow, block, or modify a particular item of this person- 5 
al information or cookie content. For instance, the user 
may not want to include certain personal information 
that may have been obtained from sources other than 
directly from the user; such personal information might 
include income, age, hobbies, etc. 
[0031] The present invention is used by a user in two 
ways: for managing cookies in the user's cookie file 10, 
or for managing cookies in RAM. In the first way, while 
the user is either connected to the Internet or offline, the 
user activates the cookie editor 13 in file mode (as com- 
pared with RAM mode, as explained below). The cookie 
editor then presents to the user an interpreted display 
of each cookie in the cookie file 10, the interpretation 
provided through the cookie interpreter 15, using the lo- 
cal cookie dictionary 17 stored on the user's computer. 
The local cookie dictionary 17 includes at least a subset 
of the site-specific dictionary entries, and, in the pre- 
ferred embodiment, all of the (probably much smaller) 
universal cookie dictionary entries. 
[0032] Thereafter, for effective use of the present in- 
vention, every time browser 1 1 is activated by the user 
prior to customizing a cookie file, the user will access 
the universal cookie dictionary 22 and the site-specific 
cookie dictionary 21 over the Internet, using the local 
cookie dictionary manager 16. In the preferred embod- 
iment, the cookie dictionary manager will examine the 
cookie file 10 on the user's computer and extract from 
the site-specific cookie dictionary 21 the dictionary items 
needed by the cookie interpreter 15 to interpret the 
cookies in the user's cookie file 10, and will also extract 
from the universal cookie dictionary all of the dictionary 
items, so that the user has available all possible cookie 
types for communicating preferences to a website. 
[0033] According to the standard for a cookie present- 
ly proposed by the Internet Engineering Task Force (pro- 
posed standard RFC 2109), the content of a cookie in- 
cludes six parameters: 

the name of the cookie (i.e., the type of cookie); 
- the value of the cookie; 
expiration date of the cookie; 
path the cookie is valid for; 
domain the cookie is valid for; and 
whether there is a need for a secure connection to 
use the cookie. 

[0034] The name and value of a cookie are mandatory 
content, and the other four parameters can be set man- 
ually or automatically. The name (of the cookie/cookie 
variable) and value (of the cookie/cookie variable) are 
the essential content of the two cookie dictionaries 21 
and 22. For example, in the universal cookie dictionary 
22, in the preferred embodiment, there is at least a name 



and possible values that would allow a user to specify 
that the user wishes to have all advertising or product 
literature provided by, for example, first class U.S. mail; 
thus, the universal cookie dictionary 22 might include 
here a name "mail-preference," and might include as 
possible values: U.S. mail, different couriers, and per- 
haps e-mail. 

[0035] From this example, it would seem that the use 
of a cookie dictionary to enable the cookie interpreter 
15 to pass to the cookie editor 13 an interpretation of a 
cookie is not always necessary. Indeed; some of the 
names (types of cookies) are probably suggestive 
enough to reveal unambiguously the content of a cook- 
ie. However, in many cases a cookie will have a name 
that is intentionally vague so that only the website that 
set the cookie will know the content. Thus, for example, 
one bookstore company on the Internet would have a 
cookie with content that is difficult for competing book- 
stores to decipher. For this reason, in general, the local 
cookie dictionary 17 is needed. 
[0036] There is, of course, no motivation for obscuring 
the meaning of the variables in the universal cookie dic- 
tionary; thus these variables would be named as sug- 
gestively as possible. In fact, in another aspect of the 
present invention, there is no universal cookie diction- 
ary. Instead, the cookie editor 13 enables a user to cre- 
ate ad hoc variable names and corresponding values. 
It is then envisioned that website operators will discover 
that cookies are being conveyed back to their websites 
with variables not of their own devising. In that case, the 
website operator can account for these new variables 
manually, or, when a website operator discovers that a 
cookie has been returned with a new variable, the web- 
site can be configured to automatically access the uni- 
versal cookie dictionary 22 through the Internet to inter- 
pret a cookie created by a user. 
[0037] In the preferred embodiment, the cookie dic- 
tionaries 21 and 22 are maintained by a third party. Us- 
ers can communicate with the third party any sugges- 
tions they have for new variables (types of cookies) and 
their corresponding range of values by visiting the web- 
site of the third party or otherwise communicating their 
suggestions to the third party. In another aspect of the 
present invention, users maintain a universal cookie dic- 
tionary on their computers, and each website comes to 
learn that when encountering a cookie created by a user, 
the website should refer to the user's private universal 
cookie dictionary to unambiguously interpret the cookie. 
[0038] In the second way of using the present inven- 
tion, the user manages a cookie in RAM. In this case, 
when a website sets a cookie in RAM, the browser no- 
tifies the cookie interpreter and passes to the it the RAM 
address of the cookie. The cookie interpreter executes 
the cookie editor; the editor then automatically executes 
in RAM mode (compared to file mode, noted above), i. 
e., without any involvement by the user. Then the cookie 
editor attempts to interpret the cookie based on the local 
cookie dictionary. If it cannot, it directs the browser 1 1 
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to access the site-specific cookie dictionary 21 , and then 
searches that dictionary tor an interpretation of the cook- 
ie. If it locates the interpretation for the cookie, it pro- 
vides the interpretation to the cookie editor, which in turn 
displays the interpretation to the user. The user can then 
inspect the cookie, alter it, or block it. 
[0039] Another way of managing cookies in RAM is 
for a userto fabricate a cookie while accessing a website 
using the browser 1 1 . The user would do this to convey 
to the website preferences the user may want the web- 
site to know. In this scenario, the user executes the 
cookie editor 13 in RAM mode, as compared with file 
mode used to manage cookies in the cookie file, and 
then fabricates a cookie in the same way as when the 
cookie editor is executed in offline mode. When the user 
is done fabricating the cookie, the cookie editor sets the 
cookie in RAM without any further involvement by the 
user. 

[0040] Referring now to Fig. 2, a system for managing 
a user-characterizing protocol header in a general con- 
text, not necessarily the Internet, is shown. Here, a user 
(not shown) invokes an editor 32 in order to manage a 
user-characterizing protocol header (not shown) from a 
user-characterizing protocol header source 30. The ed- 
itor 32 automatically invokes an interpreter 31 , which ex- 
amines the protocol header and searches the local dic- 
tionary 33, or, alternatively, searches remote dictionar- 
ies 34 residing on a computer other than the user's. In 
the preferred embodiment, the interpreter 31 would con- 
sult the remote dictionaries 34 only if it fails to find, in 
the principal dictionary, an entry corresponding to the 
protocol header. 

[0041] The interpreter 31 prevents the user from in- 
terfacing directly with a protocol header. Ordinarily, an 
embodiment of the present invention would have the in- 
terpreter 31 even prevent the user from ever directly 
viewing a protocol header, i.e., viewing it in its native 
format, as a pure character string; although in some ap- 
plications it may be useful for the user to see what a 
protocol header "really" looks like, and an embodiment 
in which the interpreter can, optionally, provide such a 
view is intended to be within the scope of the present 
invention. 

[0042] In the usual embodiment, though, the interpret- 
er 31 passes to the editor only the content information 
in one or another dictionary sufficient for the editor to 
display the protocol header in a way that makes evident 
the meaning of each logically related subset of charac- 
ters of the character string composing the protocol 
header. The editor 32 then displays this information, and 
in the preferred embodiment does so by providing on 
the screen a name for each logically related subset of 
characters that is at least suggestive to the user of the 
meaning of the characters. If the user wants, the user 
can prompt the editor to provide additional interpretation 
of any particular subset of characters, or, preferably, the 
editor would do so whenever the user places the pointer 
from a pointing device on the field and rests it there for 



more than a brief interval. The editor 32 receives this 
additional interpretation, as well as all the other content 
information for the protocol header, from the interpreter 
31, and usually all at once, although in some embodi- 
5 ments it is preferable to provide content information only 
as needed. 

[0043] Referring now to Fig. 3 and Fig. 4, which in 
combination indicate various possible sequences of 
steps in the operation of the present invention, as shown 
in Fig. 2. 

[0044] More generally, the present invention in es- 
sence interfaces with a string of characters defining a 
protocol header on a user's computer to provide a user 
with an interpretation of at least a portion of the string 
of characters, the invention comprising: a dictionary 
containing at least one entry, the entry comprising a first 
string of characters representing at least a portion of the 
protocol header and a second string of characters rep- 
resenting a meaning associated with the first string of 
characters; an interpreter for retrieving the second string 
of characters based upon the first string of characters; 
and an editor, for displaying the second string of char- 
acters retrieved by the interpreter. The first string of 
characters is often the character string that defines the 
type of the protocol header, but need not be. In the In- 
ternet context, a website might not use a type (name of 
a cookie). Instead, it might encode within the value of 
the cookie both a type and its value. This would be done, 
for example, to make its cookies more resistant to at- 
tempts by others to decipher them. In this scenario, the 
interpreter, in examining the cookie, would find in refer- 
ring to a dictionary (principal or other) that the website 
employs such a scheme and would extract from the dic- 
tionary content data indicating an interpretation of the 
cookie without relying on the type of cookie, just its val- 
ue. 

[0045] Although a preferred embodiment of the inven- 
tion has been specifically described, it will be under- 
stood that the invention is to be limited only by the ap- 
pended claims, since variations and modifications of the 
preferred embodiment will become apparent to a person 
skilled in the art upon reference to the description of the 
invention herein. Therefore, it is contemplated that the 
appended claims will cover any such modification or em- 
bodiments that fall within the true scope of the invention. 



Claims 

1 . A system for interfacing with a string of characters 
defining a protocol header inserted on a user's com- 
puter by a server to provide a user with an interpre- 
tation of at least a portion of the string of characters, 
the system comprising: 

a dictionary (17;21;22;33;34) containing at 
least one entry, the entry comprising a first 
string of characters representing at least a por- 
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tion of the protocol header and a second string 
of characters representing a meaning associ- 
ated with the first string of characters; 
an interpreter (15;31) for retrieving the second 
string of characters based upon the first string 
of characters; and 

an editor (13;32), for displaying the second 
string of characters retrieved by the interpreter 
(15;31), said editor further enabling the user to 
edit the content of said protocol header, for con- 
veying back to said server, 
and said editor characterised in that it is ena- 
bling the user to fabricate a protocol header ex- 
pressing a preference of the user, based on an 
entry, provided by the interpreter (15;31), from 
the dictionary. 

2. The system claimed in Claim 1 , wherein the first 
string of characters defines a type for the protocol 
header. 

3. The system claimed in Claim 1 , wherein the first 
string of characters defines a value for the protocol 
header. 

4. The system of any of Claims 1 to 3, wherein said 
string of characters defines at least a type and a 
value, said dictionary is a principal dictionary (33), 
having at least one entry, each entry corresponding 
to a protocol header of a particular type, each entry 
containing content data indicating an interpretation 
of at least one type of protocol header; said inter- 
preter (31 ) is, for associating a specific entry in the 
principal dictionary (33) with a particular protocol 
header, and for providing an interpretation of the 
protocol header according to the content data con- 
tained in the entry. 

5. A system as claimed in Claim 4, wherein the inter- 
preter (31) also provides access to any entry in the 
principal dictionary (33), and wherein the editor dis- 
plays each entry provided by the interpreter (31 ). 

6. A system as claimed in Claim 5, further comprising: 

a) a universal dictionary (22), containing types 
of protocol headers not necessarily used by any 
network content provider and content data in- 
dicating interpretations of these types of proto- 
col headers, for selection by a user in convey- 
ing preferences to a network content provider; 

b) a principal dictionary manager, for updating 
the principal dictionary so as to include entries 
from the universal dictionary. 

7. A system as claimed in Claim 6, further comprising: 

a) a site-specific dictionary (21), containing at 



least one entry for a type of protocol header, 
each entry providing content data indicating an 
interpretation of at least one type of protocol 
header used by at least one network content 
5 provider. 

8. A system as claimed in Claim 7, wherein, for a pro- 
tocol header of a type not contained in the principal 
dictionary, the interpreter refers to the site-specific 
10 dictionary (21 ) to interpret the protocol header. 



Patentanspruche 

15 1. System zum AnschlieBen an eine Zeichenfolge, 
welche einen Protokoll-Header bestimmt, welcher 
durch einen Server bei einem Computer eines Be- 
nutzers eingesetzt ist, urn einem Benutzer eine In- 
terpretation von mindestens einem Abschnitt der 

20 Zeichenfolge bereitzustellen, wobei das System 
enthalt: 

ein Verzeichnis (17; 21; 22; 33; 34), welches 
mindestens eine Eingabe enthalt, wobei die 
25 Eingabe eine erste Zeichenfolge, welche min- 

destens einen Abschnitt des Protokoll-Headers 
darstellt, und eine zweite Zeichenfolge, welche 
eine mit der ersten Zeichenfolge in Verbindung 
stehende Bedeutung darstellt, enthalt; 

30 

einen Interpreter (15; 31) zum Abrufen der 
zweiten Zeichenfolge, basierend auf der ersten 
Zeichenfolge; und 

35 einen Editor (13; 32) zum Darstellen der durch 

den Interpreter (15; 31) abgerufenen zweiten 
Zeichenfolge, wobei es der Editor dem Benut- 
zer ferner ermoglicht, den Inhalt des Protokoll- 
Headers zu editieren, und zwar zur Riickuber- 

40 mittlung an den Server, 

und wobei der Editor dadurch gekennzeichnet ist, 
dass es dem Benutzer ermoglicht wird, einen Pro- 
tokoll-Header zu erzeugen, welcher eine Praferenz 
45 des Benutzers basierend auf einer vom Interpreter 
(15; 31) bereitgestellten Eingabe vom Verzeichnis 
ausdruckt. 

2. System nach Anspruch 1 , bei welchem die erste 
so Zeichenfolge einen Typ fur den Protokoll-Header 

bestimmt. 

3. System nach Anspruch 1, bei welchem die erste 
Zeichenfolge einen Wert fur den Protokoll-Header 

55 bestimmt. 

4. System nach einem der Anspruche 1 bis 3, bei wel- 
chem die Zeichenfolge mindestens einen Typ und 
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einen Wert bestimmt, wobei das Verzeichnis ein 
Hauptverzeichnis (33) ist, welches mindestens eine 
Eingabe hat, wobei jede Eingabe einem Protokoll- 
Header eines bestimmten Typs entspricht, wobei 
jede Eingabe Inhaltsdaten enthalt, welche eine In- 5 
terpretation von mindestens einem Typ an Proto- 
koII-Header anzeigt; wobei der Interpreter (31 ) dazu 
dient, eine spezifische Eingabe im Hauptverzeich- 
nis (33) mit einem bestimmten Protokoll-Header in 
Verbindung zu bringen, und eine Interpretation des n> 
Protokoll-Headers gemaG den in der Eingabe ent- 
haltenen Inhaltsdaten bereitzustellen. 

5. System nach Anspruch 4, bei welchem der Inter- 
preter (31) ebenfalls einen Zugriff auf jegliche Ein- 15 
gaben im Hauptverzeichnis (33) bereitstellt, und bei 
welchem der Editor jede durch den Interpreter (31) 
bereitgestellte Eingabe anzeigt. 

6. System nach Anspruch 5, welches ferner enthalt: 20 

a) ein Universalverzeichnis (22), welches Ty- 
pen an Protokoll-Header, welche nicht notwen- 
digerweise von irgendeinem Netzwerk-lnhalt 
Anbieter verwendet werden, und Inhaltsdaten 25 
enthalt, welche Interpretationen dieser Typen 

an Protokoll-Header anzeigen, damit ein Be- 
nutzer beim Ubermitteln von Praferenzen an ei- 
nen Netzwerk-lnhalt Anbieter auswahlen kann; 

30 

b) einen Hauptverzeichnis-Verwalter zum der- 
artigen Aktualisierendes Hauptverzeichnisses, 
so dass es Eingaben vom Universalverzeichnis 
enthalt. 

35 

7. System nach Anspruch 6, welches ferner enthalt: 

a) ein fur einen Einsatzort spezifisches Ver- 
zeichnis (21), welches mindestens eine Einga- 
be fur einen Typ an Protokoll-Header enthalt, *o 
wobei jede Eingabe Inhaltsdaten bereitstellt, 
welche eine Interpretation von mindestens ei- 
nem Typ an Protokoll-Header anzeigen, wel- 
cher von mindestens einem Netzwerk-lnhalt 
Anbieter verwendet wird. 45 

8. System nach Anspruch 7, bei welchem der Inter- 
preter bei einem Protokoll-Header von einem Typ, 
welcher nicht im Hauptverzeichnis enthalten ist, auf 
das fur den Einsatzort spezifische Verzeichnis (21 ) so 
Bezug nimmt, um den Protokoll-Header zu interpre- 
tieren. 



Revendications 55 

1. Systeme d'interfacage avec une .chaine de carac- 
teres definissant un en-tete de protocole insert sur 



I'ordinateur d'utilisateur par un serveur pour donner 
a I'utilisateur une interpretation d'au moins une par- 
tie de la chaine de caracteres, le systeme 
comprenant : 

un dictionnaire (17 ; 21 ; 22 ; 33 ; 34) contenant 
au moins une entree, I'entree comprenant une 
premiere chaine de caracteres repr^sentant au 
moins une partie de I'en-tete de protocole et 
une deuxieme chaine de caracteres repr^sen- 
tant une signification assoctee a la premiere 
chaine de caracteres ; 

un interpr&eur (15 ; 31) destine a extraire la 
deuxieme chaine de caracteres sur la base de 
la premiere chaine de caracteres ; et 
un editeur (13 ; 32) destine a afficher la deuxie- 
me chaine de caracteres extratte par Tinterpr6- 
teur (15 ; 31), ledit 6diteur permettant en outre 
a I'utilisateur d'6diter le contenu dudit en-tete 
de protocole, pour le reacheminement vers le- 
dit serveur, 

et ledit editeur etant caracterise en ce qu'il 
permet a I'utilisateur de fabriquer un en-tete de 
protocole exprimant une preference de I'utilisa- 
teur, sur la base d'une entree, fournie par I'in- 
terpreteur (15 ; 31), a partir du dictionnaire. 

2. Systeme selon la revendication 1, dans lequel la 
premiere chaine de caracteres d6finit un type pour 
I'en-tete de protocole. 

3. Systeme selon la revendication 1, dans lequel la 
premiere chaine de caracteres definit une valeur 
pour I'en-tete de protocole. 

4. Systeme selon I'une quelconque des revendica- 
tions 1 a 3, dans lequel ladite chaine de caracteres 
definit au moins un type et une valeur, ledit diction- 
naire est un dictionnaire principal (33), ayant au 
moins une entree, chaque entree correspondant a 
un en-tete de protocole d'un type particulier, chaque 
entr6e contenant des donn^es de contenu indi- 
quant une interpretation d'au moins un type d'en- 
tete de protocole ; ledit interpreter (31) est destine 
a associer une entree specifique dans le dictionnai- 
re principal (33) a un en-tete de protocole particu- 
lier, et a fournir une interpretation de I'en-tete de 
protocole selon les donnees de contenu contenues 
dans I'entree. 

5. Systeme selon la revendication 4, dans lequel Tin- 
terpr&eur (31) donne 6galement acces a toute en- 
tree dans le dictionnaire principal (33), et dans le- 
quel l'6diteur affiche chaque entree fournie par I'in- 
terpr&eur (31). 

6. Systeme selon la revendication 5, comprenant en 
outre : 
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a) un dictionnaire universel (22), contenant des 
types d'en-tetes de protocole pas necessaire- 
ment utilisees par tout fournisseur d'informa- 
tions reseau et des donnees de contenu indi- 
quant des interpretations de ces types d'en-te- 5 
tes de protocole, pour la selection par un utilt- 
sateur en acheminant des preferences vers un 
fournisseur d'informations reseau ; 

b) un gestionnaire de dictionnaire principal, 
destine a mettre a jour le dictionnaire principal n> 
de facon a comprendre des entrees depuis ie 
dictionnaire universe!. 

7. Systeme selon la revendication 6, comprenant en 
outre : *5 

a) un dictionnaire sp§cifique d'un site (21 ) con- 
tenant au moins une entree pour un type d'en- 
tete de protocole, chaque entree fournissant 
des donnees de contenu indiquant une inter- ' 20 
prelatton d'au moins un type d'en-tete de pro- 
tocole utilisee par au moins un fournisseur d'in- 
formations reseau. 

8. Systeme selon la revendication 7, dans lequel, pour 25 
un en-tete de protocole d'un type non contenu dans 

le dictionnaire principal, I'interpreteur se refere au 
dictionnaire specifique d'un site (21) pour interpre- 
ter I'en-tete de protocole. 
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